home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Reverse Code Engineering RCE CD +sandman 2000
/
ReverseCodeEngineeringRceCdsandman2000.iso
/
RCE
/
YTC Cracking Library
/
revx1.txt
< prev
next >
Wrap
Text File
|
2000-05-25
|
4KB
|
87 lines
Who needs this tutorial?
Cracking newbies, esp. softice newbies trying to find working ser.
nbrs. and/or right place to crack/patch.
What do you need?
A prog that shows you a nag screen when entering a wrong ser.nbr.
(but should also work with "normal" nag screens with OK buttons -
aka windows dialogs).
---------------------------cut here------------------------------(fart here)
I call the following procedure the "break in - dive out" method.
It's a general way to crack progs with serial numbers and/or nag
screens, in other words: a systematic approach to get what you need.
And I think it's a nice alternative to setting a bpx on a bogus serial.
Some of you may already use it without knowing. Ok, here we go...
phase1: Let's prepare for take-off.
Launch the prog you want to crack. Bring up the dialog that
asks for the ser.nbr. After typing a bogus number in, fire up softice
and set a breakpoint on an api-call of your choice - well, of course
on one, that is called BEFORE the "wrong serial"-window pops up. I
recommand HMEMCPY (works pretty often). Now go back to the program,
hit Enter. Back in Softice (hopefully)...
phase2: Finding the "root of all evil".
You are now at the beginning of the api-call you've set the breakpoint
before. Now disable that breakpoint. Hit F12 as often as necessary
to get into the prog's PROT32 mode. Ok, now set a breakpoint on the
actual address (ie. doubleclick the asm source in code window).
Now comes a repetetive task: hit F12 again, set new breakpoint on
actual address, delete or disable old breakpoint. Repeat this until
the "wrong serial"-window pops up.
phase3: "Let's break in".
Ok, the nag screen showed up, but you luckily have set a breakpoint
before this happened. Re-enter your bogus serial number again. Hit
Enter. If everything works fine you should now be back in Softice
again at the last breakpoint before the "nagging msg". Start tracing
with F10 (not F8). Every time you come to a "call" set a breakpoint
on it, step over it. If the nag screen does not come up, delete or
disable the breakpoint and keep on tracing (F10). At some time the
nag screen will show up, but don't worry, you have luckily set a
breakpoint on last call before nag-screen. Enter your bogus serial
number again. Hit Enter. Back in Softice (hopefully) at the last call
before the nag screen. Step into the call (F8). Delete or disable the
breakpoint and trace on with F10. Do the same as above. At every call
set a breakpoint, trace on or step in, and so on. (I think you get the
point now). What you do is to locate the core of the nag message by
stepping deeper and deeper into calls and code. Somewhere at the core
is an api-call to SHOWWINDOW or MESSAGEBOX, etc...OR: There might be
a call to a "collection of api-calls" - look at the (pushed) addresses
before the calls! You might "see" what the procedure will do or
display. All we did was to focus on the "nag-core" systematically step
by step.
phase4: "Let's dive out".
Now that we've found the right "level" of procedures and subroutines
we do the final steps. Inspect the code before the nag screen
(api-) call. Chances are good there's somewhere a CMP between good and
bad serial number. Depending on this result, the SHOWWINDOW (or
whatever) will be executed or not. If you think you have found the
right CMP look at the code that is executed when good and bad
ser. nbr. are equal. There might be a SHOWWINDOW too...(but this time
with "thank you for registering" ;). If there's no CMP at that
"level" you must leave the actual procedure (F12) and look in the
next (higher) "hierarchy" (before the call from which you just dived
out). Still no CMP? Repeat above until you find the good one. (It
may also be a TEST).
phase5: "Take a deep breath".
When you have the right CMP in front of you, you can either write
down address of the JZ/JNZ (or whatever) to patch afterwards or
you just read out good serial number (you should prefer latter one).
In some cases the good and bad serials are crypted before compare.
You should try to find the encryption routine for getting a valid
serial number. This routine is probably placed very close to the
compare. (Look at the calls before the call to the cmp procedure).
The rest is up to you!
Well, I hope this tutorial was a little help to you, good luck!
RevX